Since we’ve consolidated pre-commit into main.yml, IMO adding needs: pre-commit to the tests job would be nice. Currently, all jobs will run in parallel, but it would be better to make the tests depend on the pre-commit results to prevent unnecessary runs when there are linting errors.".

Having them run in parallel gives you more feedback when they both fail for different reasons, you can fix both in one go this way. What you're suggesting might have pre-commit hide a problem in tests which you would only discover after fixing the linting error.

I agree with your point here , But I assume people likely do testing of their code before pushing in most scenario, But most of time they forgot to run pre-commit locally. so in such scenario the test jobs will run two times which might be costlier.

I thought this would be a trivial change that didn't deserve its own pull request, but you having a differing viewpoint proved me that it's not that trivial, so I've moved this out of this change:

• Merge pre-commit workflow into main #9857

Will be a better place to discuss it - will hide the previous comment as outdated from here to not pollute this PR

Actually I should probably update the release process at the same time.

 Create pull request for [release notes](https://github.com/encode/django-rest-framework/blob/mains/docs/topics/release-notes.md) based on the [*.*.* milestone](https://github.com/encode/django-rest-framework/milestones/***).
 Update supported versions:
 Ensure the pull request increments the version to `*.*.*` in [`restframework/__init__.py`](https://github.com/encode/django-rest-framework/blob/main/rest_framework/__init__.py).
 Ensure documentation validates 
 Confirm that release is finalized and ready to go. 
 Ensure that release date is included in pull request.
 Merge the release pull request.
-Install the release tools: `pip install build twine`
-Build the package: `python -m build`
-Push the package to PyPI with `twine upload dist/*`
-Tag the release, with `git tag -a *.*.* -m 'version *.*.*'; git push --tags`.
-Deploy the documentation with `mkdocs gh-deploy`.
+Create the git tag
+Wait for the release workflow to run. It will build the distribution, upload it to Test PyPI, PyPI and create the GitHub release
 Make a release announcement on the [discussion group](https://groups.google.com/forum/?fromgroups#!forum/django-rest-framework).
-Make a release announcement on twitter.
+Make a release announcement on social media.
 Close the milestone on GitHub.

Edit: that's now done

@auvipy @peterthomassen I'm keen try get 3.17 released in the coming days and would like to try using this for it. I can't really test this until it's merged but it's pretty much the @django-commons template that's used on several projects, so should hopefully work 🤞🏻

I think I should also be invited to PyPI as an decade old contributor to DRF

I think I should also be invited to PyPI as an decade old contributor to DRF

Fair enough. Done on PyPI and test PyPI - although this workflow is meant to remove the need to invite maintainers altogether